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STUDY  PROJECT  COALS: 

1.  Identify  configuration  management  requirements  for  major  defense  systems 
development. 

2.  Translate  these  requirements  to  a computer  system  environment. 

3.  Present  a general  approach  to  configuration  management  for  the  Base  Level 
Data  Automation  Program  (Phase  IV). 


STUDY  REPORT  ABSTRACT 


This  study  examines  configuration  management  as  defined  in  Department  of 
Defense  publications  for  major  defense  systems  and' applies  configuration 
management  to  the  development  of  computer  systems.  DOD  Directives,  DOD 
Instructions,  Military  Standards,  and  Air  Force  publications  provide  the 
primary  source  of  configuration  management  principles  and  functions.  Con 
figuration  management  has  haa  limited  application  to  embedded  computer 
systems  and  even  less  to  general  purpose  computer  systems.  The  study  dis 
cusses  configuration  management  principles  in  the  computer  system  environ 
ment  and  concludes  that  these  principles  can  be  and  should  be  applied  to 
the  c*evelo'ment  of  computer  systems.  To  d-ronstrate  that  conclusion,  the 
principles  are  applied  to  a specific  Air  Force  program,  the  Base  Level 
Data  Automation  Program  (Phase  f jl). 
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EXECUIVE  SUMMARY 


The  increasing  complexity,  cost,  and  dependence  on  computer  systems 
demand  better  management  of  their  development.  Configuration  Management 
is  one  component  of  the  total  management  structure  where  considerable  im- 
provement is  needed.  Configuration  Management  is  a well-defined  discipline 
when  applied  to  classical  major  defense  system  development  where  hardware 
is  the  primary  end  item.  Most  of  the  publications  within  the  Department 
of  Defense  consider  Configuration  Management  a vital  part  of  controlling 
development  and  there  is  considerable  guidance  available.  However,  Con- 
figuration Management  has  had  limited  application  to  embedded  computer  sys- 
tems and  even  less  to  general  purpose  computer  systems.  Configuration 
Management  principles  are  examined  to  determine  if  the  discipline  defined 
for  major  defense  systems  can  be  applied  to  the  development  of  computer 
systems. 

Configuration  Management  consists  of  three  functions;  configuration 
identification  which  identifies  the  baseline  configuration  of  a configura- 
tion item,  configuration  control  which  controls  all  changes  to  the  baseline, 
and  configuration  status  accounting  which  tracks  and  reports  status  of  con- 
figuration items  and  applicable  changes. 

Reviews  and  Audits  are  a part  of  the  Configuration  Management  process 
and  provide  a method  for  accomplishing  the  three  functions  and  tie  Configu- 
ration Management  into  the  total  development  process. 

It  is  concluded  that  the  Configuration  Management  principles  defined 
for  the  major  defense  system  environment  can  be  and  should  be  applied  to 
computer  systems.  Specific  procedures  will  have  to  be  adapted  and  tailored 
to  the  computer  system  development  process,  but  the  principles  are  valid. 
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CHAPTER  I 
Introduction 

Problem:  The  US  Air  Force  has  experienced  considerable  difficulty  in  the 

recent  past  in  the  development  of  major  computer  systems  such  as  the  Ad- 
vanced Logistics  System  (ALS),  the  Base  Automated  Systems  for  Total  Opera- 
tion (BASE-TOP),  and  the  Tri-Service  Medical  Information  System  (TRIMIS). 

It  is  the  opinion  of  this  author  that  many  of  the  difficulties  were  due 
to  the  system  of  management  and  control  expressed  in  the  Air  Force  300 
series  regulations.  These  directives,  while  having  served  well  for  earlier 
development,  do  not  provide  adequate  management  of  the  development  process 
required  for  today's  large  and  complex  systems.  In  contrast,  the  manage- 
ment of  the  defense  system  development  process  is  well  defined  in  the  USAF 
800  series  regulations  in  conjunction  with  applicable  Military  Standards 
and  DOD  publications.  This  paper  will  focus  on  one  aspect  of  this  manage- 
ment process,  that  of  Configuration  Management  (CM). 

The  directives  within  the  Department  of  Defense  that  address  CM  are 
written  for  the  acquisition  process  of  major  defense  systems.  When  the 
subject  of  computer  software/hardware  is  addressed,  it  is  addressed  in  terms 
of  an  embedded  computer  system  which  is  one  component  of  the  total  defense 
system.  There  is  considerable  guidance  on  CM  in  this  environment  versus 
a limited  amount  for  the  development  of  computer  systems.  The  term  computer 
system  is  used  in  this  paper  to  denote  those  computer  system  developments 
which  are  not  directly  related  to  a weapon  system  and  with  emphasis  on 
computer  software.  Systems  such  as  ALS,  BASE-TOP,  and  TRIMIS  are  considered 
to  be  computer  systems  in  this  context.  Because  of  the  increasing  complexity 
of  computer  systems  there  is  a recognized  need  to  improve  the  management  of 
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their  development. 

Purpose:  In  view  of  the  fact  that  additional  CM  guidance  is  needed  for 

computer  system  development,  the  primary  purpose  of  this  paper  is  to  exa- 
mine the  CM  principles  in  the  major  defense  system  environment  and  assess 
their  appl icabil vty  to  the  computer  system  environment.  Improved  CM  is  one 
step  in  providing  improved  total  program  management. 

Scope:  This  paper  is  intended  to  be  academic  in  nature  and  confined  pri- 

marily to  the  major  principles  and  functions  of  CM.  It  is  not  intended  to 
detail  specific  procedures  nor  develop  a CM  plan.  There  are  examples  and 
outlines  of  CM  plans  in  various  other  documents.  Chapter  IV  will,  however, 
discuss  these  principles  in  relation  to  a specific  Air  Force  program,  the 
Base  Level  Data  Automation  Program  (Phase  IV). 

Limitations : Configuration  Management  has  been  receiving  increased  atten- 

tion at  all  levels  in  the  Department  of  Defense  and  many  of  the  applicable 
documents  are  in  the  process  of  extensive  revision.  This  is  especially  true 
with  respect  to  the  Air  Force  documents.  Hence,  this  report  should  be  viewed 
by  later  readers  in  the  time  frame  in  which  it  is  written.  Secondly,  the 
reader  should  be  aware  that  the  author  has  limited  experience  in  CM.  Part 
of  the  purpose  in  writing  this  report  was  to  gain  a better  knowledge  of  CM 
activities.  Thirdly,  because  of  the  limited  time  available  for  preparation, 
research  on  the  topic  was  restricted  primarily  to  existing  documentation. 

A logical  next  step,  once  CM  principles  are  understood,  would  be  to  investi- 
gate how  these  principles  are  actually  employed  at  the  operating  level. 
Organization:  The  paper  is  organized  to  provide  the  reader  first  with  a 


familiarity  for  what  publications  address  CM  and  what  they  generally  contain. 


Chapter  III  will  attempt  to  provide  an  understanding  of  what  CM  is  as  de- 
fined in  those  publications  and  how  the  CM  concepts  apply  to  computer  systems. 
Chapter  IV  will  then  discuss  these  concepts  in  relation  to  a specific 
Air  Force  program.  Phase  IV. 
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CHAPTER  II 


Current  Policies  and  Directives 

There  are  numerous  publications  which  discuss  Configuration  Management 
(CM)  and  have  an  impact  on  CM  activities.  This  chapter  will  discuss  those 
considered  most  germane  to  the  CM.  To  discuss  these  publications  it  is 
necessary  to  have  a basic  idea  of  what  CM  is.  DODD  5010.19  defines  CM  as 
"a  discipline  applying  technical  and  administrative  direction  and  surveil- 
lance to  (a)  identify  and  document  the  functional  and  physical  characteris- 
tics of  a configuration  item;  (b)  control  changes  to  those  characteristics; 
and  (c)  record  and  report  change  processing  and  implementation  status." 

(12-.2)1 

The  three  key  words  are  identify,  control,  and  status.  These  are  the 
three  main  functions  of  CM,  often  referred  to  as  configuration  identifica- 
tion, configuration  control,  and  configuration  status  accounting.  A detailed 
discussion  of  what  these  functions  are  and  what  they  mean  to  CM  will  be 
given  in  the  next  chapter. 

POD  Directives,  and  Instructions:  Probably  what  could  be  considered  the  root 

document  of  CM  is  DODD  5010.19,  "Configuration  Management."  It  contains 
overall  policy  guidance  on  the  use  of  CM  and  defines  some  terms  applicable 
to  CM.  It  briefly  explains  the  functions  of  CM,  identification,  control, 
and  status  accounting.  It  directs  that  CM  be  applied  to  "all  CIs  (Confi- 
guration Items)  procured  for  use  by  the  DOD  or  obtained  through  an  agreement 
between  in  house  activities."  Once  CM  has  been  initiated  for  a Cl,  it  will 
continue  until  the  Cl  is  removed  from  the  operational  inventory.  (12:3) 

1.  This  notation  will  he  used  throughout  the  report  for  sources  of  quotation 
and  references.  The  first  number  is  the  source  listed  in  the  Bibliography. 

The  second  is  the  page  in  the  reference. 
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As  stated  in  DODD  5010.19,  objectives  of  CM  are  to  (1)  assist  manage- 
ment in  the  development  of  a Cl;  (2)  introduce  controls  at  the  appropriate 
time  during  development,  but  yet  allow  maximum  latitude  for  design  trade- 
offs; (3)  efficiently  manage  changes;  and  (4)  "attain  the  optimum  degree 
of  uniformity"  across  all  organizations  involved  in  the  development  of  the 
Cl.  (12:2) 

DODI  5010.21  covers  the  same  CM  functions  and  concepts  introduced  in 
DODD  5010.19  but  in  greater  detail,  clarifies  some  of  the  terms,  and  defines 
additional  ones.  Under  configuration  identification  it  discusses  the  func- 
tional, allocated  and  product  configuration  identifications  which  tie  CM 
to  the  baselines  established  during  the  development  cycle  of  a Cl.  These 
points  are  critical  to  the  CM  activity  for  it  is  from  these  baselines  that 
the  configuration  is  established  and  controlled.  (13:2) 

The  discussion  of  configuration  control  identifies  two  types  of  changes, 
appropriately  called  Class  I and  Class  II.  Class  I changes  are  of  such 
significance  that  they  affect  the  Government's  interest  in  that  they  affect 
the  function,  interfaces  with  other  CIs,  performance,  costs,  or  delivery  to 
the  Government.  Class  I changes  require  the  approval  of  the  Government. 

Class  II  changes  are  of  minor  significance  and  consist  primarily  of  small 
changes  to  effect  correction  of  documentation  or  detail  design.  (13:4) 

This  instruction  also  expands  on  configuration  audits,  specifically  a 
Functional  Configuration  Audit  (FCA)  and  a Physical  Configuration  Audit 
(PCA).  The  FCA  is  a "means  of  validating  that  development  of  a Cl  has  been 
completed  satisfactorily,  i.e.,that  the  item  will  perform  as  intended."  The 
PCA  establishes  that  the  Cl  produced  matches  its  configuration  identification. 
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Several  other  documents  mention  CM  and  usually  refer  to  one  of  the 
documents  described  above.  For  instance,  DODD  5000.29,  "Management  of  Com- 
puter Resources  in  Major  Defense  Systems,"  mentions  CM  in  paragraph  V, 

Policy.  It  states  simply,  "Defense  System  computer  resources,  including 
both  computer  hardware  and  computer  software  will  be  specified  and  treated 
as  configuration  items.  Baseline  implementation  guidance  for  this  action 
is  contained  in  DODI  5010.21."  (11:2) 

It  should  be  noted  that  these  documents  are  usually  interpreted  to 
apply  CM  to  the  major  defense  system  acquisition  process.  As  a point  in 
contrast,  DODI  5010.27,  "Management  of  Automated  Data  System  Development," 
which  could  be  considered  the  top  document  for  development  of  computer  sys- 
tems, neither  mentions  CM  nor  uses  as  reference  any  CM  related  document. 

Even  at  the  highest  levels  there  has  been,  to  date,  little  consideration  of 
the  importance  of  CM  to  the  development  of  computer  systems.  The  problem  has 
just  begun  to  surface  because  of  recent  software  difficulties  resulting  from 
the  growing  complexity  of  software  both  for  major  defense  systems  and  general 
purpose  support. 

Military  Standards:  The  primary  military  standards  that  deal  with  CM  are 

480,  481,  432,  483,  490  and  1521.  No  one  document  covers  the  CM  spectrum, 
but  Mil-Std  483  is  probably  the  most  comprehensive  in  that  regard.  Mil-Std 
483,  "Configuration  Management  Practices  for  Systems,  Equipment,  Munitions, 
and  Computer  Programs,"  is  broken  into  two  parts.  The  first  part  gives  the 
general  requirements  for  CM.  The  second  part  provides  a number  of  appen- 
dices which  are  intended  to  provide  guidance  for  the  preparation  of  docu- 
ments related  to  CM  and  not  covered  in  other  Mil-Stds.  It  establishes 
supplementary  requirements  in  the  following  configuration  management  areas: 
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a. 

Configuration  Management  Plan 

b. 

Configuration  Identification 

c. 

Interface  Control 

d. 

Configuration  Audits 

e. 

Engineering  Release  Control  and  Control 

of  Engineering  Changes 

f. 

Configuration  Management  Reports/Records 

(3:1) 

The  other  Mil-Stds  go  into  great  detail  on  one  specific  aspect  of  CM. 

Mil -Std  490,  "Specification  Practices,"  describes  the  various  specifications. 
The  specification  documents  identify  the  configuration.  Hence,  Mil -Std  490 
is  aimed  at  the  configuration  identification  function  of  CM. 

Mi  1 -Std  430,  "Configuration  Control-Engineering  Changes,  Deviations 
and  Waivers,"  and  Mil-Std  481,  "Configuration  Control-Engineering  Changes, 
Deviations  and  Waivers  (short  form),"  are  aimed  at  configuration  control. 
Mil-Std  482,  "Configuration  Status  Accounting  Data  Elements  and  Related 
Features,"  provides  guidance  for  the  third  CM  function  status  accounting. 
Mil-Std  1521,  "Technical  Reviews  and  Audits  for  Systems,  Equipment,  and 
Computer  Programs,"  describes  a review  and  audit  process. 

Reviews  and  audits  are  a key  element  in  the  development  of  any  system. 
Depending  on  the  point  of  view,  a system  of  reviews  could  be  either  included 
or  excluded  as  part  of  CM.  The  FCA  and  PCA  are  traditionally  considered  a 
CM  function.  While  other  reviews  may  not  technically  be  a part  of  the  CM 
definition,  they  play  a key  role  for  the  Configuration  Manager.  Since  they 
tie  directly  to  the  approval  of  specifications  for  the  configuration  identi- 
fication function,  the  approval  of  changes  for  configuration  control,  and  the 
audit  of  the  actual  configuration  for  the  status  accounting  function,  the 
reviews  and  audits  are  often  treated  as  a part  of  the  responsibility  of  the 
Configuration  Manager.  They  will  be  so  treated  for  the  purpose  of  this 


paper. 
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In  sum,  this  set  of  Mil-Stds  provide  considerable  guidance  for  CM. 

As  with  the  DOD  directives,  these  standards,  when  addressing  computer  pro- 
grams, do  so  primarily  in  terms  of  a computer  program  being  part  of  a major 
defense  system. 

Air  Force  Publications:  The  Air  Force  documents  that  address  CM  are  based 

on  the  DOD  and  Mil-Std  documents  just  discussed.  Much  of  the  terminology 
is  consistent  with  these  documents.  AFSCP  800-3,  "A  Guide  for  Program  Man- 
agement," discusses  CM  as  it  applies  to  Program  Management.  Chapter  9 gives 
an  excellent  synopsis  of  the  entire  spectrum  of  CM  to  include  Configuration 
Audits.  AFR  65-3,  "Configuration  Management,"  is  a joint  service  regulation 
which  attempts  to  implement  DOD  policy  and  guidance.  AFSCM/AFLCK  375-7, 
"Systems  Management  Configuration  Management  for  Systems,  Equipment,  Muni- 
tions and  Computer  Programs,"  goes  into  great  detail  about  every  aspect  of 
CM.  Because  of  this  detail  it  loses  some  of  its  effectiveness.  However, 
used  as  a guide,  it  can  be  of  considerable  help  to  the  configuration  manager 
in  preparing  the  CM  plan  and  establishing  CM  procedures.  AFR  800-14,  "Ac- 
quisition and  Support  Procedures  for  Computer  Resources  in  Systems,"  ad- 
dresses CM  of  computer  resources  more  directly.  It  attempts  to  differenti- 
ate CM  during  the  validation,  full-scale  development  and  early  production 
phases  versus  the  later  production  and  deployment  phases  when  emphasis 
changes  from  identification  to  change  control.  It  also  provides  for  the 
establishment  of  a Computer  Program  Configuration  Sub-Board  as  a subordi- 
nate element  to  the  Change  Control  Board,  for  the  purpose  of  reviewing  Com- 
puter Program  Configuration  Item  ( CPC  I ) changes  which  do  not  affect  system 
equipment.  These  publications  are  all  pointed  to  the  major  defense  system 
acquisition  process  and  address  computer  systems  only  as  a part  of  that 


process . 


To  date,  the  acquisition  and  development  of  computer  systems  with- 
in the  Air  Force  have  followed  the  300  series  publications,  which  describe 
a quite  different  process.  With  respect  to  CM  specifically,  only  fleeting 
references  are  made.  Some  of  the  classical  CM  functions  are  mentioned  under 
the  guise  of  phrases  such  as  control  of  design  and  development  and  Automatic 
Data  Processing  Systems  (ADPS)  management,  but  there  is  no  defined  discipline 
for  CM.  However,  within  the  last  12  months,  the  Director  of  Data  Automation 
of  the  Air  Force  has  recognized  that  the  process  of  ADPS  acquisition  and 
management  needs  to  be  strengthened.  One  of  the  areas  receiving  much  empha- 
sis is  configuration  management. 

The  DOD,  Mil-Std,  and  Air  Force  publications  discussed  in  this  chapter 
are  the  primary  ones  concerned  with  CM.  There  is  notably  a lack  of  guidance 
in  the  computer  systems  area  and  specifically  for  those  systems  not  related 
to  major  defense  systems.  It  may  be  significant  to  observe  that  the  DOD 
publications  and  the  Mil-Stds  were  published  to  a large  extent  between  1968 
and  1970.  The  size  and  complexity  of  embedded  computer  systems  as  well  as 
general  computer  systems  have  grown  considerably  in  just  the  last  6 years. 

The  need  for  applying  CM  to  embedded  computer  systems,  particularly  soft- 
ware, is  just  now  emerging.  The  Air  Force  has  also  recognized  the  need  for 
CM  on  systems  being  developed  cn  general  purpose  equipment.  The  next  chap- 
ter will  relate  the  CM  principles  in  the  publications  discussed  to  the 
environment  of  the  latter. 


CHAPTER  III 


Configuration  Management 

In  the  previous  chapter  the  primary  directives  which  pertain  to 
Configuration  Management  were  discussed.  This  chapter  will  describe  how 
'CM  concepts  transfer  to  the  computer  system  environment. 

Computer  System  Development  Cycle:  It  is  first  necessary  to  have  an  under- 

standing of  the  development  cycle  for  a computer  system.  The  major  phases 
are  quite  similar  to  those  depicted  for  major  defense  systems.  The  acti- 
vities within  these  phases,  however,  differ  significantly  at  some  points. 

While  most  papers  that  address  the  computer  development  cycle  discuss 
the  same  general  concepts  and  steps,  there  is  no  generally  accepted  agree- 
ment on  the  nomenclature  nor  groupings  of  the  steps.  For  the  purpose  of 
this  paper,  the  cycle  described  in  the  Air  Force  Data  System  Design  Center 
Manual  (AFDSDCM)  300-8  (test)  will  be  used.  This  manual  is  in  a test  phase 
and  is  one  of  the  first  documents  addressing  computer  systems  produced  by 
the  Air  Force  which  incorporates  some  of  the  management  techniques  used  in 
major  defense  system  development. 

The  development  process  described  in  the  manual  consists  of  five  phases 
(1)  conceptual,  (2)  definition,  (3)  development,  (4)  test,  and  (5)  opera- 
tions. 

The  conceptual  phase  covers  the  writing,  approving  and  reviewing  of 
requirements  for  data  automation  support.  During  this  phase  the  user  identi 
fies  and  justifies  the  need  for  Automatic  Data  Processing  (ADP)  support  to 
fulfill  a mission  or  operational  requirement.  The  conceptual  phase  con- 
concludes  with  a Preliminary  Requirements  Review  (PRR)  which  approves  or 


disapproves  further  work.  (5:2-9) 

The  definition  phase  has  three  primary  tasks.  One  is  to  develop  a 
Functional  Description  (FD)  which  is  a detailed  description  of  the  functional 
process  being  considered  for  ADP  support.  It  describes  "the  logical  work 
flows  of  activities  and  events  and  information  flow  in  the  existing  user 
environment."  (1:2-10)  The  second  task  in  this  phase  is  to  develop  a Data 
Project  Plan  (DPP).  This  plan  is  a comprehensive  management  plan  describing 
how  the  project  will  be  developed,  who  the  players  are,  the  milestone  sche- 
dule, and  the  resources  required.  It  is  a description  of  the  action  neces- 
sary to  achieve  system  performance,  project  schedule  and  cost  objectives. 
(1:2-10,  1 : A2-2 ) The  third  task  is  to  develop  alternative  methods  for 
satisfying  the  requirement.  These  alternatives  are  evaluated  and  a recom- 
mended method  is  proposed  for  concept  certification  at  the  System  Require- 
ments Review  (SRR).  The  FD  identifies  the  functional  baseline.  The  FD  and 
DPP  remain  "live"  documents  throughout  the  life  of  the  system. 

Once  concept  certification  has  been  granted,  the  project  moves  to  the 
development  phase.  During  this  phase  detailed  design  is  completed.  Before 
programming  begins  the  design  is  reviewed  and  approved  which  establishes  the 
allocated  baseline.  The  development  phase  ends  when  the  programming  and 
checkout  are  completed. 

During  the  test  phase,  the  systems  software  and  documentation  are 
thoroughly  evaluated  both  at  the  development  facility  and  at  test  field 
sites.  Both  the  product  and  operational  baselines  are  established  during 
this  phase.  (1 : 2-1 0) 

During  the  final  phase,  the  operations  phase,  the  system  is  transferred 
from  the  developer  to  the  user  going  through  an  implementation/conversion 


period.  An  operational  evaluation  is  provided  to  the  developer  by  the 
user  after  a period  of  operation.  Maintenance  and  product  improvement  con- 
tinue throughout  the  life  of  the  system.  Major  modifications  will  normally 
go  through  the  full  development  cycle  before  incorporation  into  the  opera- 
tional system. 

AFDSDCM  300-8  (test)  breaks  these  phases  into  17  steps  shown  in  figure 
1 which  is  taken  from  the  manual.  Of  particular  interest  for  this  paper, 
is  the  fact  that  the  figure  shows  configuration  management  beginning  dur- 
ing the  definition  phase. 

Using  this  computer  system  development  cycle  as  a basis,  lets  look  at 
how  the  configuration  management  concepts  described  briefly  in  Chapter  II 
for  major  defense  systems,  translate  to  the  computer  system  environment. 

The  management  of  computer  system  development  has  problems  which  are 
unique  and  management  techniques  used  for  the  hardware  of  major  defense 
systems  cannot  be  transferred  en  tote.  Some  of  the  obvious  differences 
are: 

1.  Computer  projects  often  produce  a one  of  a kind  item  as  op- 
posed to  the  production  of  a quantity  of  the  same  item.  Hence,  the  major 
portion  of  the  cost  is  all  at  the  front  end  and  cannot  be  amortized  over  a 
production  quantity. 

2.  Computer  projects  are  not  concerned  with  the  logistics  of 
spare  parts.  There  are  no  spares.  The  problem  of  maintainability  is  in  an 
entirely  different  context. 

3.  Computer  projects  are  more  concerned  with  the  functional  de- 
sign requirements,  than  with  the  physical  design.  The  crux  of  a successful 
computer  system  is  the  reliabi  ity  of  the  software  and  whether  it  performs 
the  required  mission. 
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4.  Changes  to  computer  programs  require  a complete  retesting  of 
the  program  module  to  verify  that  the  change  has  not  impacted  the  program 
function  or  caused  an  interface  problem  with  other  modules.  (14:3) 

In  the  specific  discipline  of  configuration  management,  however,  the 
concepts  applied  to  hardware  have  much  to  offer  the  CM  of  computer  systems. 
While  some  of  the  specific  procedures  must  be  different,  the  basic  concepts 
can  be  applied.  The  rest  of  this  chapter  will  discuss  how  the  concepts  of 
CM  apply  to  computer  systems  development. 

Configuration  Identification:  Configuration  identification  is  "the  current 

approved  or  conditionally  approved  technical  documentation  for  a configura- 
tion item  as  set  forth  in  specifications,  drawing  and  associated  lists, 
and  documents  referenced  therein."  (12:2)  The  configuration  item  (Cl)  in 
terms  of  software  is  a computer  program  or  set  of  computer  programs,  desig- 
nated as  a Computer  Program  Configuration  Item  (CPC I ) . However,  not  every 
computer  program  should  be  a CPCI.  As  with  hardware,  CPC I s should  be 
identified  based  on  whether  they  satisfy  an  end  use  function,  are  key  pro- 
grams, have  expected  interface  problems  or,  in  the  judgment  of  the  Program 
Manager,  to  provide  added  visibility  to  a particular  computer  program.  Be- 
cause of  this  selectivity,  a CPCI  may  vary  greatly  in  program  size.  A CPCI 
can  be  broken  into  one  or  more  computer  program  components  (CPC)  which  can 
be  thought  of  as  a performing  one  of  more  of  the  sub-functions  necessary 
to  accomplish  the  end  item  function  of  the  CPCI. 

The  technical  documentation  for  a CPCI  is  not  the  same  as  for  hard- 
ware Cl.  In  Air  Force  terminology,  the  technical  documentation  consists 
primarily  of  a System/Subsystem  Specification  (SS)  and  a Program  Specifi- 
cation (PS).  The  SS  specifies  system  performance,  interfaces  with  other 
CPCIs,  data  requirements  and  other  technical  requirements  in  sufficient 
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detail  to  permit  detailed  design  of  the  system  components.  The  SS  is 
the  document  which  is  reviewed  at  the  System  Design  Review  and  identifies 
the  allocated  baseline.  (6:3-6) 

A PS  is  usually  written  for  each  CPC  of  the  CPCI.  It  consists  of 
the  detailed  technical  description  of  tne  CPC,  the  flow  charts,  interfaces 
with  other  CPCs  and  when  completed,  a listing  of  the  actual  computer  instruc- 
tions. (6:4-10) 

The  SS  and  PS  are  somewhat  analogous  to  the  Part  I and  Part  II  speci- 
fications described  in  Mil-Std  490.  There  are  often  other  documents  re- 


quired to  completely  specify  the  CPCI  or  the  relationship  of  one  CPCI  to 
another.  The  Data  Requirements  Documents  (RD)  lists  and  defines  data  ele- 
ments that  will  be  used  within  the  CPCI.  This  can  be  a key  document  when 
developing  systems  with  a large  number  of  CPCIs  since  it  defines  the  format 
and  size  of  the  data  elements  and  provides  standardization  for  common  data 
elements.  A second  document  which  is  related  to  the  RD  is  the  Data  Base 
Specification  (DS).  The  DS  specifies  the  organization  of  the  data  elements 
within  the  computer  and  allows  the  programmer  to  generate  the  required  files, 
tapes,  and  dictionaries  for  the  CPC.  (6:12)  The  RD  and  DS  are  necessary  in 
large  systems  to  define  the  interfaces  between  CPCIs  and  CPCs.  The  docu- 
ments and  a suggested  format  are  described  in  detail  in  DOOM  4120.17, 
"Automated  Data  Systems  Documentation  Standards  Manual." 

The  function  of  configuration  identification  also  includes  the  number 
and  marking  of  CPCIs,  CPCs  and  their  documentation.  The  development  of  a 
numbering  and  marking  scheme  is  another  subject  within  itself  and  will  not 
be  discussed  here.  Some  of  the  things  that  need  to  be  considered  in  develop- 
ing that  scheme  are  the  documents  that  are  to  be  numbered.  These  may 
include  more  than  just  the  specification  documents  such  as  users  manuals. 


test  reports,  or  management  plans.  The  CPCI  number,  CPC  number,  version 
number,  version  description  document  number,  change  identification  num- 
bers all  need  to  be  considered  as  well  as  identifiers  to  be  used  within 
the  computer  itself  to  mark  tapes,  disc  packs  or  other  storage  media  for 
programs  and  data  files.  (22:21) 

Configuration  Control:  Configuration  Control  is  the  "systematic  evalu- 

ation, coordination,  approval  or  disapproval,  and  implementation  of  all 
approved  changes  in  the  configuration  of  a Cl  after  formal  establishment 
of  its  configuration  identification."  (12:2)  For  CPCIs,  configuration 
control  consists  of  managing  the  changes  which  affect  the  baselines. 

It  is  appropriate  at  this  point  to  digress  and  discuss  the  idea  of 
baseline  management.  Baseline  management  is  a key  concept  to  configuration 
management.  The  baseline  is  the  reference  point  on  which  further  develop- 
ment and  control  are  based.  Documents  are  identified  which  describe  that 
baseline  and  any  changes  must  be  approved,  controlled  and  documented.  The 
following  baselines  are  usually  established  during  the  development  of  the 
system. 

1.  Functional  baseline.  This  baseline  provides  the  detailed 
definition  of  what  the  user  says  is  required.  The  functional  baseline  is 
established  at  the  System  Requirements  Review  which  approves  the  Functional 
Description  (FD)  document  as  well  as  the  methodology  for  satisfying  the 
requirement. 

2.  Allocated  baseline.  This  baseline  provides  the  system  defi- 
nition of  how  the  requirements  in  the  FD  are  to  be  satisfied.  The  System/ 
Subsystem  specification  (SS)  is  the  applicable  document  and  its  approval 
at  the  Systems  Design  Review  establishes  the  allocated  baseline. 

3.  Product  baseline.  This  baseline  provides  detailed  design  of 
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the  CPCIs  and  CPCs  required  to  perform  the  functions  required  by  the  SS. 

The  principle  document  is  the  Program  Specification  (PS).  The  product 
baseline  is  established  after  developer  testing  is  completed,  but  prior 
to  operational  field  testing. 

4.  Operational  baseline.  Once  the  operational  test  has  been 
satisfactorily  completed,  the  system  is  ready  for  implementation.  At  this 
point  the  operational  baseline  is  established.  This  baseline  is  really  a 
refinement  of  the  product  baseline  and  includes  corrections  made  by  the 
developer  for  errors  discovered  during  field  testing.  (A  field  test  is  a 
joint  test  coducted  by  the  developer  and  user  under  operational  conditions.) 
Other  documents  may  come  under  configuration  control  at  this  time  such  as 
the  users  manual,  computer  operators  manual,  and  maintenance  manual.  (1:2-9) 

Any  changes  to  these  baselines,  once  established,  must  be  controlled. 

The  process  of  approval  and  control  is  the  function  of  configuration  control. 

There  are  two  types  of  changes,  Class  I and  Class  II.  Class  I changes 
are  those  changes  which  are  of  such  significance  that  it  affects  one  of  the 
established  baselines  in  terms  of  performance,  schedule,  cost  or  user  re- 
quirements. Class  II  changes  do  not  affect  the  technical  content  of  the 
baseline  documents  and  are  typically  minor  corrections  to  documentation  or 
programming  errors. 

As  with  hardware,  changes  are  initiated  via  an  Engineering  Change  Pro- 
posal (ECP).  However,  DD  Form  1692,  ECP,  should  not  be  required.  A form 
more  appropriate  to  software  changes  should  be  designed  for  use  during  the 
computer  system  development.  AFR  300-xx  contains  a recommended  ECP  form 
for  computer  systems.  Each  ECP  is  required  to  define  the  proposed  change, 
the  need  or  justification  for  the  change,  impacts  on  any  other  part  of  the 
system  functions,  estimated  resources,  loth  cost  and  manpower,  and  a 


milestone  schedule  for  accomplishment.  (6:27) 

A major  role  in  the  control  of  the  changes  is  played  by  the  Configura- 
tion Control  Board  (CCB).  The  CCB  must  review  and  evaluate,  and  approve/ 
disapprove  all  Class  I changes.  The  priority  of  Class  I changes  can  be  the 
same  or  similar  to  that  described  in  DODI  5010.21  as  emergency,  urgent,  and 
routine.  Software  changes  will  have  to  be  made  on  the  same  basis.  It  is 
important  to  recognize  that  both  the  documentation  and  the  operational  pro- 
gram need  to  be  controlled.  A computer  program  is  an  intangible  product 
and  if  strict  procedures  for  implementing  changes  are  not  established,  pro- 
grammers will,  because  of  their  nature,  tend  to  put  "small"  changes  into  the 
system  which  have  an  affinity  for  having  a greater  impact  than  the  program- 
mer anticipated  or  realized.  Once  a Class  I change  is  approved  it  goes 
through  much  the  same  development  and  test  process  that  the  original  system 
went  through. 

The  changes  to  the  configuration  documentation  and  the  computer  programs 
must  be  rigidly  controlled  and  processed  and  approved  in  a systematic  way. 
Changes  must  be  tracked  and  reviewed  much  the  same  as  in  the  original  develop- 
ment. The  third  function  of  CM  does  this  record  keeping. 

Configuration  Status  Accounting:  Configuration  Status  Accounting  is  "the 

recording  and  reporting  of  the  information  that  is  needed  to  manage  configu- 
ration effectively,  including  a listing  of  the  approved  configuration  identi- 
fication, the  status  of  proposed  changes  to  configuration,  and  the  imple- 
mentation status  of  approved  changes."  (12:2)  For  computer  systems  it 
involves  the  recording  and  reporting  of  the  identification  and  status  of 
the  evolving  CPCIs,  provides  traceability  of  past  problems,  corrective 
actions,  status  of  changes  in  process  and  the  responsible  office(s)  working 
the  changes,  and  maintaining  the  correlation  between  the  documenfation  and 


the  computer  programs. 

Configuration  status  accounting  is  primarily  a bookkeeping  function. 

To  keep  track  of  the  information  a series  of  logs  is  designed.  If  the 
size  of  the  system  is  large  enough  it  may  be  desirable  to  automate  the  re- 
cord keeping.  Various  types  of  logs  and  indices  are  suggested  by  references 
6 and  23.  A key  one  is  the  configuration  index  which  provides  the  status 
of  each  CPCI  and  the  proposed  changes  to  the  CPCI.  Each  CPCI  is  entered 
into  the  configuration  index  as  it  is  identified  and  baselined.  As  develop- 
ment of  the  CPCI  continues  the  configuration  index  is  updated  to  reflect  the 
latest  status.  The  CPCI  is  in  the  configuration  index  throughout  the  life 
of  the  CPCI. 

In  addition  to  the  documents  which  specify  the  configuration,  the 
status  of  each  document  such  as  the  users  manual,  maintenance  manual,  de- 
scription document,  and  computer  operators  manual  should  be  tracked.  These 
documents  are  also  an  important  part  of  the  function  of  the  total  system. 

In  short,  Configuration  Status  Accounting  supports  the  functions  of 
identification  and  control  by  providing  the  record  keeping  necessary  to 
maintain  control.  Another  aspect  of  CM,  which,  while  not  a specific  function 
of  CM,  is  an  integral  part  of  the  CM  process  is  that  aspect  of  the  system 
of  reviews  and  audits. 

Reviews  and  Audits:  A system  of  reviews  and  audits  is  the  methodology  by 

which  CM  performs  its  functions  of  identification  and  control.  There  are 
basically  two  kinds  of  reviews  and  audits.  The  first  are  the  reviews  which 
look  at  the  requirements  and  design.  These  are  scheduled  at  major  mile- 
stones during  the  development  cycle.  The  purpose  of  these  reviews  is  to 
formally  assess  and  approve/disapprove  the  work  done  to  date  and  provide 
guidance  for  further  efforts. 


Referring  again  to  Figure  1,  the  System  Requirements  Review  marks  the 
end  of  the  definition  phase  and  establishes  the  functional  baseline.  The 
System  Design  Review  marks  the  end  of  system  design  and  establishes  the 
allocated  baseline.  The  draft  AFR  300-XX,  reference  6,  describes  the  con- 
ceptual phase  and  definition  phase  and  their  reviews  in  different  words  than 
AFDSDCM  300-8  (test),  but  the  same  activities  occur  and  both  result  in  the 
functional  and  allocated  baselines  being  established  as  a result  of  a parti- 
cular review. 

The  second  kind  of  reviews  and  audits  is  verification  oriented  as  op- 
posed to  management  and  approval  oriented.  A Functional  Configuration  Audit 
(FCA)  and  Physical  Configuration  Audit  (PCA)  are  conducted  during  step  13 
of  Figure  1.  The  draft  AFR  300-XX  calls  this  activity  the  Product  Verifi- 
cation Review  of  which  the  successful  completion  establishes  the  product 
baseline  The  FCA  in  this  context  means  a "formal  examination  of  the  test 
data  for  a configuration  item's  functional  characteristics,"  while  the  PCA 
is  "the  formal  examination  of  the  coded  version  of  a computer  program  con- 
figuration item  against  its  technical  documentation."  (6:A-4,5)  In  other 
words,  the  FCA  insures  that  the  functions  required  by  the  SS  are  satisfied 
by  the  CPCI  whereas  the  PCA  matches  the  performance  of  the  CPCI  against  its 
design  specifications  and  associated  manuals  to  insure  that  the  documenta- 
tion is  complete. 

The  System  Verification  Review  is  conducted  at  the  completion  of  all 
testing  including  field  testing,  and  establishes  the  operational  baseline 
certifying  that  the  system  is  ready  for  distribution  and  operational  use. 

The  system  of  reviews  and  audits  provides  the  configuration  management 
function  with  the  necessary  methods  and  formal  approval  steps  from  which  to 
conduct  the  three  functions  of  CM,  identification,  control  and  status 


accounting.  These  reviews  and  audits  tie  the  configuration  manager  into  the 
total  management  of  the  development  and  also  with  the  Quality  Assurance  func- 
tion. The  FCA  and  PCA  are  the  first  steps  required  for  Quality  Assurance 
and  most  likely  will  involve  the  participation  of  personnel  from  that  function. 

This  chapter  has  discussed  some  of  the  principles  of  CM  as  used  in 
major  defense  systems  development  and,  with  the  assistance  of  some  new  and 
draft  Air  Force  documents,  has  attempted  to  show  their  applicability  to  com- 
puter system  development.  There  is  much  similarity,  but  the  definition  of 
functions  and  terms  need  to  be  adopted  to  the  computer  environment.  However, 
the  principles  can  be  and  should  be  applied.  The  next  chapter  tries  to 
relate  these  principles  to  a specific  Air  Force  program.  The  Base  Level  Data 
Automation  Program  (Phase  IV). 


CHAPTER  IV 


Configuration  Management  Principles 
Applied  to  the  Ease  Level  Data  Atomation  Program  (Phase  IV) 

Having  looked  at  what  CM  is  and  how  it  generally  applies  in  the  com- 
puter system  environment,  let's  look  at  how  CM  might  apply  in  a specific 
program  environment.  The  program  that  will  be  addressed  is  the  Base  Level 
Data  Automation  Program  (Phase  IV). 

Background:  The  Phase  IV  program  is  a program  to  replace  the  standard  com- 

puters installed  at  major  Air  Force  bases  throughout  the  world.  The  Air 
Force  currently  has  two  standard  computers.  One  is  the  U1050-II  which 
is  used  to  process  the  Standard  Base  Supply  System  (SBSS).  This  computer 
has  been  in  use  since  1963  and  is  located  at  126  sites.  The  other  standard 
computer  is  the  compatible  set  of  B3500/B4700  computers  which  is  located 
at  117  sites.  The  Burroughs  computers  have  been  in  use  since  1968  and  are 
used  to  provide  general  purpose  computing  support  to  such  functional  areas 
as  finance,  personnel,  civil  engineering,  vehicle  maintenance,  medical,  etc. 
In  addition,  a Remote  Job  Entry  Terminal  System  (RJETS)  is  being  used  to 
provide  support  to  small  Air  Force  facilities,  the  Air  Force  Reserve,  and 
the  Air  National  Guard.  (10:2,20) (20: A-l ) 

These  two  standard  computers  have  reached  the  point  where  it  is  no 
longer  considered  economical  to  repair  nor  feasible  to  further  augment 
their  inherent  capabilities.  The  Air  Force  has  concluded  that  it  is  neces- 
sary to  replace  these  computers  with  a family  of  computers  which  are  com- 
patible with  each  other  and  can  be  sired  to  accommodate  the  different  com- 
puter loading  requirements  of  the  various  Air  Force  installations.  The 
program  received  concept  certification  on  12  October  1976  and  has  just 


formally  moved  into  the  definition  phase.  Considerable  work  has,  however, 
already  been  done  for  the  definition  phase  because  of  work  accomplished  on 
two  previous  programs  recently  cancelled  that  had  similar  objectives. 

The  Phase  IV  program  has  targeted  world-wide  implementation  to  begin 
in  mid-1981.  Initially,  this  may  seem  like  a long  lead  time,  but  in  exa- 
mining the  steps  necessary  to  reach  that  point  with  their  associated  time 
consumption,  mid-1981  may  be  optimistic.  One  of  the  big  time  eaters  is  the 
procurement  process  which  is  planned  to  take  over  2 years  for  developing 
the  Request  for  Proposal  (RFP),  evaluating  the  proposals  and  making  the  con- 
tract award.  This  schedule,  in  my  opinion,  is  not  at  all  pessimistic.  Be- 
cause of  the  size  of  the  equipment  procurement,  past  Air  Force  experience 
indicates  the  selection  will  be  highly  competitive  and  fraught  with  problems. 

The  transition  of  the  software  is  also  a sizeable  task  and  involves 
a large  number  of  organizations.  For  the  B3500/B‘,1700  alone,  there  are  over 
600  different  software  systems  consisting  of  over  7000  programs  and  over  20 
responsible  organizations  involved.  Software  of  this  magnitude  and  diver- 
sity will  require  a comprehensive,  controlled,  coordinated  conversion  ef- 
fort. This  presents  a real  management  challenge.  The  Configuration  Manager 
will  play  a key  role  in  this  process  and  will  have  a number  of  significant 
issues  to  deal  with. 

With  the  large  number  of  programs  involved,  one  of  the  first  issues 
is  to  determine  what  level  of  control  is  needed  and  at  what  level  CPCIs 
should  be  establ ished--sys terns  level  or  program  level?  In  most  cases  it  is 
expected  that  the  CPCI  should  be  established  at  the  systems  level.  However, 
systems  consisting  of  a large  number  of  programs  should  be  considered  for 
breaking  into  several  CPCIs.  Each  system  needs  to  be  examined  to  determine 
the  level  of  control  necessary.  As  stated  hi  Chapter  III,  the  designation 


of  a CPCI  should  be  by  the  best  judgment  of  the  program  management  team, 
and  not  set  arbitrarily. 

A more  slippery  problem  than  the  designation  of  CPCIs  is  defining  the 
configuration  baselines,  the  functional,  allocated,  product,  and  opera- 
tional baselines.  Since  many  of  the  systems  to  be  transitioned  have  been 
operational  for  a number  of  years,  any  functional  baseline  in  the  text  book 
sense  has  probably  been  long  since  obscured  by  many  modifications,  which 
have  affected  the  original  functional  methodology  as  well  as  the  operation 
of  the  system.  This  is  also  true  to  a certain  extent  of  the  allocated  and 
product  baselines.  It  would  be  difficult  for  the  organization  responsible 
for  the  CPCI  to  produce  complete  documentation  to  support  these  baselines. 
There  is,  however,  an  operational  baseline  that  has  been  maintained  by  AFDSDC. 
The  systems  have  evolved  over  a period  of  time  and  as  they  now  exist  meet  a 
group  of  specifications  instead  of  a single  integrated  one. 

Configuration  Identification:  This  situation  presents  a problem  for  the  CM 

function  of  identification.  Identification  of  CPCIs  is  based  on  having  ade- 
quate documentation  to  describe  the  functional  and  systems  requirements.  If 
existing  documentation  does  not  adequately  define  the  CM  baselines,  should 
additional  documentation  be  generated  to  produce  those  documents  normally 
associated  with  the  baselines?  The  answer  is  somewhat  dependent  on  how  the 
software  is  to  be  transitioned.  AFDSDC  and  the  Phase  IV  Program  Management 
Office  (PMO)  are  considering  four  approaches  for  transition  at  the  present 
time.  These  four  are  Translation,  Reprogramming/Redes ign,  Simulation  and  Emul 
tion.  Simulation  and  emulation  are,  in  my  opinion,  only  temporary  solutions 
since  all  systems  must  (or  at  least  should)  be  eventually  converted  to  run  di- 
rectly on  the  new  hardware  to  tale  advantage  of  new  features  and  techniques. 
The  primary  advantage  of  using  these  two  methods  is  that  the  initial  workload, 
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to  get  the  system  "on  the  air"  with  the  new  hardware,  is  reduced  and  it  is  pro- 
bable that  faster  implementation  would  be  achieved.  This  is  contingent,  of 
course,  on  the  availability  of  an  adequate  simulator  or  emulator,  or  both. 


Even  for  a direct  translation  effort,  a reprogramming/redesign  effort 
would  seem  appropriate  at  some  future  date.  It  is  recognized  that  the  first 
objective  of  the  transition  must  be  to  get  systems  operational  on  the  new 
hardware  in  the  scheduled  time  frame.  The  second  objective,  to  utilize  the 
full  capabilities  of  the  new  hardware,  may  have  to  take  a back  seat,  but  at 
some  point  reprogramming/redesign  will  have  to  be  done. 

If  a reprogramming/redesign  effort  will  occur,  changes  to  the  system 
must  be  reviewed  and  approved  against  the  same  baseline.  In  view  of  this, 
we  may  be  inclined  to  answer  the  question  p^sed  earlier,  concerning  pre- 
paring additional  documentation,  with  a yes,  since  both  the  functional  and 
allocated  baselines  will  change.  There  is,  however,  another  aspect  that 
needs  to  be  considered  before  giving  a definite  answer. 

Because  the  transition/implementation  period  is  over  an  extended  length 
of  time,  it  would  be  undesirable  to  freeze  the  design  of  all  systems  at  an 
early  time  and  prohibit  any  further  development  and  implementation  of  en- 
hancements. Consequently,  the  Program  Management  Office  is  establishing 
three  conversion  baselines  (these  baselines  should  not  be  confused  with  the 
four  CM  baselines).  These  three  baselines  are  the  transition  baseline,  the 
implementation  baseline,  and  the  projected  requirements  baseline.  The 
transition  baseline  consists  of  all  currently  operational  systems  or  ap- 
proved systems  and  enhancements  scheduled  for  implementation  on  the  B3500 
or  U1050  that  will  transition  to  the  new  Phase  IV  hardv/are.  This  includes 
general  support  software  as  well  as  application  software.  The  implementation 
baseline  is  the  transition  baseline  plus  those  systems  or  enhancements  that 
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will  be  developed  specifically  for  the  new  hardware  and  will  be  a part  of 
the  total  Phase  IV  implementation  process.  The  projected  requirements  base- 
line consists  of  functional  user  requirements  or  system  enhancements  that 
are  not  yet  approved.  Some  of  these  may  become  approved  and  will  then  be- 
come part  of  the  implementation  baseline.  (9:1) 

In  view  of  the  above,  the  answer  to  the  additional  documentation  ques- 
tion can  not  be  a definitive  yes  or  no.  While  the  situation  requires  the 
examination  of  more  information  than  the  author  has  at  the  present  time,  the 
following  is  proposed. 

For  operational  systems  that  have  an  established  operational  baseline 
and  will  be  transitioned  without  modification,  the  transition/implementation 
should  be  treated  no  different  from  a modification  to  the  system  as  currently 
handled  under  AFDSDC,  Major  Air  Command  (MAJCOM),  Special  Operating  Agencies 
(SOA)  procedures.  A translation  of  these  systems  will  produce  little  if  any 
functional  impact,  therefore,  it  is  not  perceived  necessary  to  create  develop- 
ment documentation  for  systems  which  are  already  in  operational  use  just  for 
the  sake  of  documenting  CM  baselines. 

The  same  rationale  holds  for  those  systems  for  which  enhancements  will 
be  made  prior  to  implementation.  However,  the  proposed  enhancements  should 
come  under  CM  scrutiny  and  be  included  in  the  change  proposal  process  so 
that  the  impact  on  the  total  transition  process  can  be  accurately  assessed. 

It  may  not  be  necessary  for  approval  action  to  be  taken  by  the  Configuration 
Control  Board  ( CCB ) , but  certainly  the  manager  of  each  system  should  insure 
that  any  enhancements  are  necessary  and  that  it  would  be  disadvantageous  to 
wait  until  conversion  to  the  Phase  IV  hardware. 

Any  new  development  for  the  Phase  IV  hardware  should  be  subject  to  the 
entire  CM  process,  whether  it  is  to  be  an  enhancement  to  an  existing  system 


or  an  entirely  new  requirement.  If  it  is  an  add-on  to  an  existing  system 


only  that  aspect  of  it  need  be  considered  for  formal  CM.  It  is  reasonable 
to  anticipate  that  as  additional  and  new  requirements  are  generated  for  the 
Phase  IV  hardware,  new  systems  will  evolve  to  the  extent  that  the  CM  base- 
lines will  be  fully  substantiated  by  appropriate  documentation. 

From  the  preceding  discussion,  it  is  clear  that  the  CM  function  of 
identification  for  the  Phase  IV  program  is  a complicated  and  elusive  prob- 
lem. A great  deal  of  effort  and  coordination  will  have  to  be  put  into  this 
function  to  insure  that  the  efforts  of  the  various  organizations  involved 
are  using  the  same  basis  and  are  directed  toward  a common  goal. 

Configuration  Control:  The  process  of  configuration  control  should  also 

be  based  on  the  conversion  baselines  described  by  the  Phase  IV  PMO.  Once 
the  transition  baseline  is  identified  and  prior  to  implementation  of  the 
Phase  IV  hardware,  changes  should  be  processed  and  approved  at  the  lowest 
appropriate  level.  Existing  systems  will  continue  to  encounter  processing 
problems  that  can  be  fixed  by  minor  code  changes.  These  changes  would  not 
require  CCB  approval  since  they  are  Class  II  type  changes  as  discussed  in 
Chapter  III.  These  changes  do  not  affect  the  functional  nor  system  opera- 
tion. However,  the  change  processing  procedure  needs  to  be  sufficiently 
defined  to  insure  that  adequate  documentation  accompanies  the  change. 

Also,  Class  I type  changes  which  affect  only  the  transition  baseline 
would  riot  require  CCB  action.  However,  these  changes  must  be  approved  at 
such  a level  that  the  change  can  be  assessed  for  the  impact  on  systems  prior 
to  Phase  IV  implementation  as  well  as  problems  created  by  the  change  for 
transition  to  the  new  hardware.  This  level  most  likely  would  be  the  Single 
Manager  for  the  MAJCOM,  SOA  systems,  or  the  ADPS  Manager  at  AFDSDC  for 
standard  systems J Approving  authorities  should  forward  these  changes  to 


the  Phase  IV  configuration  manager  for  information  and  recording.  It  may 
be  advisable  in  some  instances  to  forward  decision  responsibility  to  the  CCB 
if  there  is  an  impact  on  the  overall  conversion  effort. 

Under  the  implementation  baseline,  new  development  will  come  under  CM 
change  control  procedures.  Once  baselines  are  established  for  new  CPCIs, 
then  as  the  development  proceeds,  any  changes  to  the  baseline  will  be  con- 
trolled. Class  II  changes  may  be  approved  by  the  ADPS  manager  or  Single 
Manager,  but  Class  I changes  should  be  processed  through  the  CCB.  Likewise, 
any  projected  requirements  that  become  part  of  the  impel ementation  baseline 
will  come  under  the  control  of  the  Phase  IV  configuration  manager. 

The  CCB  occupies  an  important  position  in  the  Phase  IV  development.  The 
following  is  a suggested  membership  for  the  CCB: 


Phase  IV  Program  Manager 


Chairman 


Phase  IV  Deputy  Program  Manager  Alternate  Chairman 

Chief  System  Engineering  PMO 

Chief  Program  Control  PMO 

Chief  Configuration  Management  PMO* 

ADPS  Manager  or  Single  Manager  AFDSDC/MAJCOM** 


Functional  Representative 


AFDSDC/HQ  USAF*** 


*The  configuration  manager  may  or  may  not  be  a full 
member.  In  either  case,  he  acts  as  a secretariat 
for  the  CCB  and  provides  the  necessary  administra- 
support. 


One  individual  for  each  MAJCOM  and  SOA  is  designated  as  the  Single 
Manager  responsible  for  all  ADP  systems  within  his  command  or  acti- 
vity. For  standard  systems,  which  are  primarily  developed  by  AKDSDC, 
a responsible  official  is  designated  as  the  ADPS  Manager  for  each 
ADPS  program,  such  as  the  IJ3500  program. 


**The  manager  whose  system  is  affected  by  the  change 
will  be  designated  as  a member  of  the  CCB  by  the 
chairman  for  review  of  his  system. 

***A  functional  representative  whose  function  is  af- 
fected will  be  designed  as  a member  of  the  CCB  by 
the  chairman.  This  representative  could  be  select- 
ed from  either  the  functional  personnel  at  AFDSDC 
cr  the  Air  Staff,  or  at  the  discretion  of  the  chair- 
man both  could  be  included. 

It  is  not  the  role  of  the  CCB  to  make  policy  or  initiate  changes.  Its 
function  is  to  assess  the  impact  of  a change,  insure  that  an  adequate  evalu- 
ation has  been  made,  that  all  interfaces  have  been  examined  and  to  recom- 
mend to  the  chairman  approval/disapproval . The  approval/disapproval  authori 
ty  rests  solely  with  the  chairman,  the  Program  Manager.  Once  the  chairman 
approves  a change  it  is  the  task  of  the  Configuration  Management  Office  to 
insure  that  implementation  action  is  initiated  and  to  track  the  change 
through  development  to  implementation. 

Configuration  Status  Accounting:  The  effort  to  provide  this  record  keeping 

activity,  as  well  as  maintaining  status  on  the  large  number  of  systems 
currently  in  existence  and  proposed  for  the  new  hardware,  will  be  sub- 
stantial. This  activity  is  the  third  CM  function.  Configuration  Status 
Accounting.  The  author  is  not  sufficiently  knowledgeable  of  the  Phase  IV 
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program  to  describe  the  particulars  as  to  how  to  accomplish  this  task.  Be- 
cause of  the  large  number  of  systems  and  the  expected  volume  of  changes, 
an  automated  record  keeping  system  should  bo  considered.  AFDSDC  uses  an 
automated  system  to  perform  part  of  this  task  and  it  should  be  investigated 


to  determine  its  applicability  to  the  Phase  IV  environment. 

Reviews  and  Audits:  In  determining  the  reviews  and  audits  process  as 

discussed  in  Chapter  III,  consideration  has  to  be  given  as  to  how  the  CPCI 
will  be  transitioned.  For  those  CPCIs  that  will  be  translated  with- 
out modification,  no  special  reviews  should  be  required  other  than  to  be 
included  in  status  reviews  to  track  their  progress.  If,  however,  modifi- 
cations are  made,  those  modifications  should  be  subject  to  design  reviews 
to  insure  that  all  interfaces  have  been  examined.  A modified  FCA  and  PCA 
should  be  conducted  in  conjunction  with  the  Quality  Assurance  activity  to 
check  the  transitioned  system  against  its  Phase  IV  documentation. 

Any  new  development  should  run  the  gamut  of  reviews  and  audits.  Only 
when  absolutely  necessary  should  special  reviews  be  conducted  by  the  PMO. 

The  PMO  should  first  insure  that  AFDSDC,  MAJCOM,  or  SOA  internal  procedures 
provide  adequate  reviews  and  audits  and  then  the  PMO  should  participate  in 
those  reviews.  Joint  reviews  will  help  provide  an  additional  avenue  for 
communication  and  cooperation. 

This  chapter  has  provided  some  of  the  author's  thoughts  on  how  CM 
should  apply  to  the  Phase  IV  program.  While  a complete  CM  plan  for  the 
Phase  IV  program  will  have  to  go  into  much  greater  depth  and  detail,  it  is 
hoped  that  these  thoughts  can  form  a basis  from  which  to  develop  the  Phase 
IV  Configuration  Management  Plan.  It  is  believed  that  the  text  book  CM 
functions,  tailored  for  this  program,  can  and  should  be  used.  The  situ- 
ation presents  some  unique  challenges  for  the  Configuration  Manager,  but  the 
use  of  CM  in  major  defense  systems  provides  some  valuable  insight  into  the 
problems  that  will  be  faced  and  gives  some  hints  as  to  how  a solution  to 
these  problems  can  be  developed. 


CHAPTER  V 

1 

Summary  and  Conclusions 

Sundry:  This  paper  has  looked  at  Configuration  Management  from  three 

different  perspectives.  First,  from  the  viewpoint  of  regulatory  documents, 
mostly  pertaining  to  major  defense  system  development,  describing  what  CM 
was,  and  where  and  how  it  was  to  be  applied.  Next,  the  definitions  in  the 
regulatory  documents  were  expanded  and  discussed  iri  the  environment  of  the 
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development  of  a computer  system.  While  the  Phase  IV  program  is  not  a 
classical  development  program,  CM  will  be  a necessary  function  for  success- 
ful implementation. 

Conclusions:  One  of  the  objectives  in  preparing  this  paper  was  to  learn 
more  about  the  subject  of  CM  and  become  more  familiar  with  the  applicable 
directives.  This  objective  was  accomplished.  The  author  was  not  aware  of 
the  number  of  directives  and  other  documents  that  pertain  to  the  CM  func- 
tion. While  most  of  these  directives  are  related  to  major  defense  systems 
development,  it  was  learned  that  the  Air  Force  has  recently  spent  considera- 
ble effort  in  examining  CM  techniques  to  apply  to  computer  systems  develop- 
ment. A number  of  documents  referred  to  in  this  paper  are  new  or  are  still 
in  draft  form.  Concern  for  adequate  CM  of  software  for  both  embedded  com- 
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% puter  systems  and  general  purpose  systems  is  growing  as  attested  by  these 

documents,  workshops  and  published  articles. 

A second  objective  was  to  determine  if  CM  principles  in  the  major  de- 
fense system  environment  could  be  applied  to  the  development  of  computer 
systems.  It  is  concluded  that  they  not  only  can  be,  but  that  it  is  being 
done.  Referring  again  to  the  Air  Force  documents  under  development  by  the 
Directorate  of  Data  Automation,  they  nave  borrowed  heavily  from  the  major 
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defense  system  documents.  Also,  some  major  defense  contractors  have  ap- 
plied these  techniques  to  their  own  software  development.  It  must  be  kept 
in  mind,  however,  that  there  are  differences  in  managing  software  as  op- 
posed to  hardware  so  some  adaptation,  mostly  in  procedure,  is  necessary. 

Thirdly,  it  is  concluded  that  CM  principles  can  be  applied  to  the 
Phase  IV  program.  The  program  has  some  unique  problems,  but  the  CM  princi- 
ples can  still  be  applied  with  some  adaptation  of  the  procedures  and 
methodology. 

Configuration  Management  is  like  any  other  discipline.  If  the  techni- 
ques and  procedures  are  realistically  constructed,  tailored  to  the  situ- 
ation, and  once  established,  adherred  to  and  followed  and  have  the  support 
of  the  participants,  then  CM  can  be  a valuable  part  of  the  total  management 
of  a program.  If  instead,  it  is  considered  only  a necessary  evil  and  not 
followed,  then  it  becomes  a yoke.  CM,  properly  applied,  can  make  a valu- 
able contribution  to  the  successful  development  of  future  computer  systems. 
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